@dgreif I was able to find it on my old laptop, but it's super hackish. Should be easier with bridge camera logic completely removed though so let me see if I can clean it up and get it to merge with this branch. I'll try to do it later today or tomorrow at the latest.

I put a somewhat cleaned up no-ffmpeg branch, using this no-bridge branch as the base, but it's not quite working yet, and I haven't managed to get to return audio yet, but it's a start. Hopefully I'll be able to figure out what I broke as it worked the last time I tested it, but it was way more hackish and didn't have the latest updates for opus-packetizer.

Awesome, thanks for looking into it! Any chance Scrypted has what we need, given that's where we got the repacketizer?

I actually brought over the latest opus-repacketizer fixes from Scrypted, so I'm thinking that's how I broke it, as it changes how packetizer works somewhat (returns an array of packets). I thought I handled everything correctly, but still digging into it a bit as it's not really obvious at the moment as I see can see the RTP packets making their way through the chain, and everything looks correct, but I get no audio. Homekit Opus audio is so incredibly picky, but it works pretty well once you get it right!

OK, as I dug into this, I realized that the problem is a bit deeper and perhaps this is not worth it. The issue is that Homekit requests a bitrate and frame duration as part of it's negotiation and, while it is tolerant of the bitrate not matching (as long as timestamps are accurately calculated) it is 100% intolerant of frame duration being different. If it requests 20ms frame duration, it really expects 20ms frames, if it requests 60ms frames, it expects 60ms frames.

So it seems, as long as the timestamps are manipulated correctly, that Homekit can deal with the 48K bitrate that Ring cameras send, even though it typically requests 24k bitrate or even lower, but it cannot deal with the fact that Ring cameras send 60ms Opus frames by default, while Homekit requests 20ms when running on LAN. For WAN/LTE, Homekit requests 60ms so just passing frames through, with nothing more than timestamp changes, appears to work just fine.

The opus-repacketizer code combines frames, so if you have 3 frames of 20ms duration, and homekit has requested 60ms duration, it will combine them into a single 60ms frame, but it doesn't split longer duration frames into smaller ones. I could code this up, but I'm wondering if it's worth it as, technically, the current behavior having ffmpeg transcode the audio to the correct bitrate/frame duration seems to be the more correct option.